By the way, I am not sure how strict we want to be matching the entire stream of instructions for this case -- it could be improved or shuffled a bit by the backend.

On the other hand, this may be easy to relax if a newer LLVM changes it.

Yea I was also wondering, it's definitely easy to relax later but would be nice to have a maintainer's opinion on this to make sure this test is not flaky. I am unfortunately not very familiar with how often LLVM changes this kind of stuff

I assume it would be fine to limit this to what differentiates it from the reg-struct-return assembly, so the calll and the retl $4, what do you think?

Yeah, like in the new ones you just added, right?

Looks like the code here was:

pub unsafe extern "C" fn builtin_call(numerator: i32, denominator: i32) -> div_t {
    // WITH-LABEL: builtin_call
    // WITH: jmp div
    // WITHOUT-LABEL: builtin_call
    // WITHOUT: pushl %esi
    // WITHOUT: subl $8, %esp
    // WITHOUT: movl 16(%esp), %esi
    // WITHOUT: subl $4, %esp
    // WITHOUT: pushl 28(%esp)
    // WITHOUT: pushl 28(%esp)
    // WITHOUT: pushl %esi
    // WITHOUT: calll div
    // WITHOUT: addl $12, %esp
    // WITHOUT: movl %esi, %eax
    // WITHOUT: addl $8, %esp
    // WITHOUT: popl %esi
    // WITHOUT: retl $4
    div(numerator, denominator)
}

Which doesn't exist anymore. For reference though, here's a way-too-detailed answer:

The above is testing a lot: both the caller side and the callee side, as well as how i32 gets passed. For ABI tests it's best to make each test function isolate one of those aspects, which gives you less to assert on. For checking returns usually that means returning some immediate value to test the callee side (like you have now), and then storing the result of a call (#145382 (comment)) to test the caller side. Then you basically only need to check that something gets written to the place you expect and can be more lax about how it gets there.

LLVM's repo has a lot more assertions about exact instruction sequences (using -NEXT), but these are usually autogenerated and run without optimizations so it's not as likely to be volatile. An example that's fresh in my head: https://github.com/llvm/llvm-project/blob/c22ec9cde3708e0c7afd0909508a67ef9625aa4c/llvm/test/CodeGen/X86/i128-fp128-abi.ll. We tend to avoid such tests in this repo because it's more painful to update when things do change, and LLVM covers ABI things pretty well.

For CHECK: directives where the ordering doesn't matter, FileCheck has CHECK-DAG. No need really to do this here, though it doesn't hurt if you feel like it (might make it possible to use the same test for the clif and gcc backends once/if those start getting asm tests).

It also has a cool feature where you can bind a regex to a name and then use it later, useful if you know it will use a scratch register but don't care which https://llvm.org/docs/CommandGuide/FileCheck.html#the-check-dag-directive.

If the assembly here is exact then that would indicate that LLVM expects the caller and callee to have the same ABI, which is good. But FileCheck only checks that lines exist in that order, not that there isn't anything between them, so that would need some WITH-NOT/WITHOUT-NOT (or -NEXT) to assert it isn't moving more things around.

However, for asm tests it's good to try to force the data to be moved in some way so you can observe it. If the function were changed to:

fn small_call(dst: &mut Ty) -> small_t {
    *dst = small();
}

Then you can assert that it does moves from specific registers to memory.